Exchange Server 2010 : Upgrading from and Coexisting with Exchange Server 2003 (part 4)

3.1. Free/Busy Functionality

In your Exchange Server 2003 environment, both free/busy functionality and offline address book distribution are provided by public folders—in particular, system folders. The Availability service in Exchange Server 2010 replaces or supplements the free/busy system folders in Exchange Server 2003, depending on the version of Outlook deployed.

In many enterprise environments, the version of Microsoft Office, and in particular Microsoft Outlook, deployed and supported to end users is managed by an IT group separate from the messaging team—usually an enterprise desktop deployment team—who must test the new version of Office extensively against the organization's standard desktop build and applications to ensure compatibility. This means that the deployment of Outlook 2007 or Outlook 2010 can be in a project plan separate from the upgrade of the messaging infrastructure to Exchange Server 2010, and users may receive the new version of Outlook before or after their mailboxes have been moved to Exchange Server 2010. So coexistence of Outlook 2003 with Exchange Server 2010 could be a major factor in your implementation.

Because the Exchange Server 2010 Availability service cannot be used by Outlook 2003, you will need to maintain system folders in your environment as long as Outlook 2003 is in use. The free/busy retrieval methodology for various clients and mailboxes is shown in Table 2.

To maintain coexistence and pave the way for a smooth upgrade to Exchange Server 2010, you need to maintain public folders, and system folders in particular, until at least all mailboxes have been moved to Exchange 2010 and all Outlook clients have been upgraded to at least Outlook 2007. In addition, if you have any custom applications that query free/busy information, ensure that these applications will be able to use the Availability service API; otherwise, you will need to maintain system folders in your environment as long as these applications are in use. Public folders coexistence and migration are discussed in more detail in the Section 7 section of this article.

3.2. OWA Coexistence

If OWA is deployed in your Exchange 2003 environment for Internet users, you must take additional steps to ensure interoperability with Outlook Web App and Exchange 2010. Exchange Server 2010 Client Access does not support accessing mailboxes from Exchange Server 2003; all legacy mailbox access is accomplished by redirecting the session to a predefined Exchange 2003 URL (typically an Exchange Server 2003 front-end server). Overall, the recommended implementation process for Exchange 2010 Client Access is as follows:

Of these steps, we will focus on configuring Exchange 2010 Client Access, managing your legacy (Exchange 2003) OWA host names, and configuring and managing digital (PKI x.509) certificates for coexistence.

To support a seamless coexistence with and upgrade from Exchange 2003 OWA, an OWA virtual directory property named Exchange2003URL was introduced in Exchange 2010 Client Access. This property is assigned on each OWA virtual directory that will be performing redirection to an Exchange 2003 front-end server. This is necessary because Exchange 2003 is not Active Directory–site aware, and does not publish settings in Active Directory—so Exchange 2010 Client Access has no means of determining which server running Exchange Server 2003 a user should be redirected to.

The following cmdlet sets the Exchange 2010 Client Access external URL for Contoso to owa.contoso.com, and sets the Exchange 2003 URL to legacy.contoso.com:

Set-OWAVirtualDirectory Seattle-EX10\OWA* -ExternalURL https://mail.contoso.com/OWA
-Exchange2003URL https://legacy.contoso.com/exchange

					  

It is recommended that a new namespace, such as legacy.contoso.com, be established for the Exchange 2003 front-end server, and the existing namespace, such as owa.contoso.com, be associated with the Exchange 2010 infrastructure. In this way, Contoso users with Exchange Server 2003 mailboxes continue to use the existing URL of https://owa.contoso.com/exchange (which now points to the Exchange Server 2010 infrastructure), and are silently redirected to https://legacy.contoso.com/exchange (the computer running Exchange Server 2003).

3.3. Digital Certificates and Exchange 2010 Client Access

Digital, or X.509, certificates are used to create the SSL-encrypted channel used by Exchange 2010 Client Access services. In addition to protecting data in transit from theft or tampering through encryption, these certificates also authenticate the server running Exchange Server 2010, providing assurance to the end user that the server is indeed the server it claims to be. This assurance is provided by the certificate in question being issued by a certification authority (CA) that the end user either chooses to trust (in the case of a Windows or other internally managed CAs), or that the user trusts because it is issued by a trusted third-party CA.

Exchange 2010 also generates a self-signed certificate automatically, but you should replace this with a certificate issued by a trusted CA. Otherwise, this certificate needs to be manually trusted by every client by manually copying it to the trusted root certificate store on each client computer or mobile device, which is generally not feasible. For Internet-facing Client Access services, the best practice is to use a SAN certificate from a trusted third-party CA.

When requesting your SAN certificate, it is best practice to minimize the number of host names requested, to minimize cost and reduce the certificate management complexity. Examples of recommended host names for Contoso are listed in Table 3.